SHOW PLAN
is an SQL statement that displays the execution plan of the previous SELECT
statement. The plan gets generated and stored during the actual execution, so profiling must be enabled in the current session before running that statement. That can be done with a SET profiling=1
statement.
To view query execution plan in JSON queries, add "profile":true
to the query. The result appears as a profile
property in the result set.
- SQL
- HTTP
SET profiling=1;
SELECT id FROM forum WHERE MATCH('i me') LIMIT 1;
SHOW PLAN;
Query OK, 0 rows affected (0.00 sec)
+--------+
| id |
+--------+
| 406443 |
+--------+
1 row in set (1.52 sec)
+------------------+----------------------------------------------------------------------+
| Variable | Value |
+------------------+----------------------------------------------------------------------+
| transformed_tree | AND(
AND(KEYWORD(i, querypos=1)),
AND(KEYWORD(me, querypos=2))) |
+------------------+----------------------------------------------------------------------+
1 row in set (0.00 sec)
In some cases the evaluated query tree can be rather different from the original one because of expansions and other transformations.
- SQL
- HTTP
SET profiling=1;
SELECT id FROM forum WHERE MATCH('@title way* @content hey') LIMIT 1;
SHOW PLAN;
Query OK, 0 rows affected (0.00 sec)
+--------+
| id |
+--------+
| 711651 |
+--------+
1 row in set (0.04 sec)
+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Variable | Value |
+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| transformed_tree | AND(
OR(
OR(
AND(fields=(title), KEYWORD(wayne, querypos=1, expanded)),
OR(
AND(fields=(title), KEYWORD(ways, querypos=1, expanded)),
AND(fields=(title), KEYWORD(wayyy, querypos=1, expanded)))),
AND(fields=(title), KEYWORD(way, querypos=1, expanded)),
OR(fields=(title), KEYWORD(way*, querypos=1, expanded))),
AND(fields=(content), KEYWORD(hey, querypos=2))) |
+------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
See also EXPLAIN QUERY. It displays the execution tree of a full-text query without actually executing the query.
SHOW PLAN format=dot
allows to return the full-text query execution tree in hierarchical format suitable for visualization by existing tools, for example https://dreampuf.github.io/GraphvizOnline :
MySQL [(none)]> show plan option format=dot\G
*************************** 1. row ***************************
Variable: transformed_tree
Value: digraph "transformed_tree"
{
0 [shape=record,style=filled,bgcolor="lightgrey" label="AND"]
0 -> 1
1 [shape=record,style=filled,bgcolor="lightgrey" label="AND"]
1 -> 2
2 [shape=record label="i | { querypos=1 }"]
0 -> 3
3 [shape=record,style=filled,bgcolor="lightgrey" label="AND"]
3 -> 4
4 [shape=record label="me | { querypos=2 }"]
}
query
property contains the transformed fulltext query tree. Each node contains:
type
: node type. Can beAND
,OR
,PHRASE
,KEYWORD
etc.description
: query subtree for this node shown as a string (inSHOW PLAN
format)children
: child nodes, if anymax_field_pos
: maximum position within a fieldword
: transformed keyword. Keyword nodes only.querypos
: position of this keyword in a query. Keyword nodes only.excluded
: keyword excluded from query. Keyword nodes only.expanded
: keyword added by prefix expansion. Keyword nodes only.field_start
: keyword must occur at the very start of the field. Keyword nodes only.field_end
: keyword must occur at the very end of the field. Keyword nodes only.boost
: keyword IDF will be multiplied by this. Keyword nodes only.
Index settings and status
SHOW INDEX STATUS
is an SQL statement that displays various per-index statistics.
The syntax is:
SHOW INDEX index_name STATUS
Displayed statistics include:
index_type
: for now that is one ofdisk
,rt
,percolate
,template
, anddistributed
.indexed_documents
andindexed_bytes
: number of indexed documents and their text size in bytes, respectively.field_tokens_XXX
: sums of per-field lengths (in tokens) over the entire index (that is used internally inBM25A
andBM25F
functions for ranking purposes). Only available for indexes built withindex_field_lengths=1
.ram_bytes
: total size (in bytes) of RAM-resident index portion.disk_bytes
: total size (in bytes) of all index files.disk_mapped
: total size of file mappings.disk_mapped_cached
: total size of file mappings actually cached in RAM.disk_mapped_doclists
anddisk_mapped_cached_doclists
: part of the total and cached mappings belonging to document lists.disk_mapped_hitlists
anddisk_mapped_cached_hitlists
: part of the total and cached mappings belonging to hit lists. Values for doclists and hitlists are shown separately since they're usually huge (say, about 90% size of the whole index).killed_documents
andkilled_rate
: the first one indicates the number of deleted documents and the rate of deleted/indexed. Technically deletion of a document just means that the document gets suppressed in search output, but physically it still persists in an index and will be purged only after merging/optimizing the index.ram_chunk
: size of RAM chunk of real-time or percolate index.ram_chunk_segments_count
: RAM chunk internally consists of segments, usually there are no more than 32 of them. This line shows the current count.disk_chunks
: number of disk chunks of the real-time index.mem_limit
: actual value ofrt_mem_limit
for the index.ram_bytes_retired
: represents size of garbage in RAM chunks (for example, deleted or replaced documents not yet finally wiped away).tid
andtid_saved
: represent the state of saving the index (real-time or percolate only).tid
gets increased with each change (transaction).tid_saved
shows maxtid
of the state saved in a RAM chunk in '.ram' file. When the numbers are different, some changes exist only in RAM and also backed by binlog (if enabled). Performing 'flush rtindex' or scheduling periodical flushing causes these changes to be saved. After flushing the binlog gets cleared, and the tid_saved
represents the actual new state.query_time_*
: query execution time statistics of last 1 minute, 5 minutes, 15 minutes and total since server start; the data is encapsulated as a JSON object which includes the number of queries and min, max, avg, 95 and 99 percentile values.found_rows_*
: statistics of rows found by queries; provided for last 1 minute, 5 minutes, 15 minutes and total since server start; the data is encapsulated as a JSON object which includes the number of queries and min, max, avg, 95 and 99 percentile values.
- SQL
- PHP
- Python
- Javascript
- Java
mysql> SHOW INDEX statistic STATUS;
+-----------------------------+--------------------------------------------------------------------------+
| Variable_name | Value |
+-----------------------------+--------------------------------------------------------------------------+
| index_type | rt |
| indexed_documents | 923981 |
| indexed_bytes | 1181846688 |
| ram_bytes | 90453512 |
| disk_bytes | 855544335 |
| disk_mapped | 848274223 |
| disk_mapped_cached | 89686016 |
| disk_mapped_doclists | 490350852 |
| disk_mapped_cached_doclists | 0 |
| disk_mapped_hitlists | 207362625 |
| disk_mapped_cached_hitlists | 0 |
| killed_documents | 107 |
| killed_rate | 0.01% |
| ram_chunk | 0 |
| ram_chunk_segments_count | 0 |
| disk_chunks | 190 |
| mem_limit | 524288 |
| ram_bytes_retired | 0 |
| tid | 0 |
| tid_saved | 0 |
| query_time_1min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| query_time_5min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| query_time_15min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| query_time_total | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| exact_query_time_1min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| exact_query_time_5min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| exact_query_time_15min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| exact_query_time_total | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| found_rows_1min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| found_rows_5min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| found_rows_15min | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
| found_rows_total | {"queries":0, "avg":"-", "min":"-", "max":"-", "pct95":"-", "pct99":"-"} |
+-----------------------------+--------------------------------------------------------------------------+
32 rows in set (0,03 sec)